home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / gnu / dejagnu.lha / dejagnu-1.0.1 / dejagnu / README < prev    next >
Text File  |  1993-05-06  |  12KB  |  262 lines

  1.   DejaGnu is a framework for testing other programs. Its purpose is to
  2. provide a single front end for all tests.  Beyond this, DejaGnu offers
  3. several advantages for testing:
  4.  
  5.         - The flexibility and consistency of the DejaGnu framework
  6.           make it easy to write tests for any program.
  7.  
  8.         - DejaGnu provides a layer of abstraction which makes all
  9.           tests (if correctly written) portable to any host or target
  10.           where a program must be tested.  For instance, a test for
  11.           GDB can run (from any Unix based host) on any target
  12.           architecture supported by DejaGnu. Currently DejaGnu runs
  13.           tests on several single board computers, whose operating
  14.           software ranges from just a boot monitor to a full-fledged,
  15.           Unix-like realtime OS.
  16.  
  17.         - DejaGnu is written in expect, which in turn uses Tcl
  18.           (Tool command language).  The framework comprises two parts:
  19.           the testing framework and the testsuites themselves. Tests
  20.           are usually written in expect using Tcl.
  21.  
  22.                How To Configure and Build
  23.  
  24.  To build DejaGnu, run the ``configure'' script here, e.g.:
  25.  
  26.         ./configure MYHOSTTYPE
  27.  
  28. followed by running ``make''.  (MYHOSTTYPE is a name for your host computer,
  29. for instance "sun4".  You can use the script ``config.sub'' to test whether
  30. a name is recognized; if it is, config.sub translates it to a triplet 
  31. specifying CPU, vendor, and OS.) This is used when you plan to
  32. configure and build in the source tree.
  33.  
  34.   If you use a separate tree for object files, (the recommended way),
  35. then the --srcdir option must also be specified. This would also
  36. require that the configure script be run from the top level directory.
  37.  
  38.     PATH/configure MYHOSTYPE --srcdir PATH/dejagnu
  39.  
  40. where PATH is is the directory that the contains the sources.
  41.  
  42.   To configure it so it gets installed somewhere other than the
  43. default of /usr/local, use the --prefix option.
  44.     
  45.     configure MYHOSTYPE --prefix [PATH]
  46.  
  47. where PATH is the prefix used to install the programs. 
  48.  
  49. See etc/cfg-paper.texi, etc/configure.texi, and/or the README files in
  50. various subdirectories, for more details. 
  51.  
  52.  As DejaGnu is a Tcl program, there is nothing to build. However, the
  53. documentation is not built by default. Use these targets:
  54. "make info"    - Convert the texinfo document to something that can
  55.           be used the GNU info program or info mode in emacs.
  56. "make dvi"    - Convert the texinfo document to something that can
  57.           be printed. This produces dvi output.
  58. "make doc"    - This builds both.
  59. "make ps"    - This converts the dvi file into postscript. This
  60.           requires a copy of dvips.
  61. "make install"    - This installs DejaGnu based on the --prefix option
  62.           when configuring. Otherwise it defaults to
  63.           /usr/local. See the DejaGnu manual for more
  64.           information on installation.
  65.  
  66.                           Changes from 0.9
  67.  
  68.         1. DejaGnu now installs itself like other utilities.
  69.         2. 700 G++ tests are included.
  70.         3. The bugs in the GCC tests have been fixed.
  71.         4. Testsuites are released separately.
  72.         5. Testsuite sources now reside with the within each tool's
  73.            source tree. 
  74.  
  75.                   Known Bugs
  76.  
  77.         1. The Tcl tests on solaris 2.x have problems with buffering of
  78.            the I/O. This causes *none* of the tests to run. This also
  79.            seems to exhibit this behaviour when the load is real heavy
  80.            on most anything or when run in the background.
  81.            HACK- use "nice -19" to upset your coworkers.
  82.         2. The expect tests are a bit flakey on Solaris 2.x and on
  83.            rare occasions any other machine.
  84.  
  85. -------------------------------------------------------------------
  86. Here's is a posting on the Free OS testing project.
  87. -------------------------------------------------------------------
  88. If you have built up your own tests for system calls, library
  89. routines, networking protocols, or common utilities, this posting
  90. offers you an opportunity to put them to good use.  You can do a good
  91. deed for the Linux community, the Berkeley UNIX community, and the
  92. wider world of free software users.
  93.  
  94. Also, if you would like to learn some good test tools and strategies,
  95. and devote some time on a volunteer basis to writing tests -- perhaps
  96. a couple of weeks full-time, or a couple hours per week over a period
  97. of several months -- then here is a project you should get involved
  98. in.
  99.  
  100. I am helping to coordinate a test effort for Linux.  In the following
  101. four sections of this message I will describe the goals, the process,
  102. the people trying to do it, and what you can do to help.
  103.  
  104. Goals
  105.  
  106.   Linux and BSD share a number of libraries and utilities, both
  107.   because BSD software was ported to Linux, and because several free
  108.   software (GNU) utilities have been ported to both operating
  109.   systems.
  110.  
  111.   Linux shows startling differences and failures as you move from one
  112.   set of hardware to another.  People who hope to base their own
  113.   commercial products on Linux would like to see proof that it is
  114.   robust, portable, and standard-conforming.  The problem is that
  115.   cross-platform testing is very hard to do, and few decent test
  116.   suites exist either for free software or for UNIX.  (Look at all the
  117.   differences you find among systems that are SVID-conforming,
  118.   particularly at higher levels such as the utilities.)
  119.  
  120.   Therefore, a number of us who are interested n Linux have decided to
  121.   enter the modern age of formal, automated software testing -- but in
  122.   a manner that is proper for the free software community.
  123.  
  124.   Using DejaGnu, a test platform developed by Cygnus Support and
  125.   placed under the GPL, we want to collect the best tests we can from
  126.   people everywhere, and integrate them into suites that any user can
  127.   download, run, and interpret with a few commands.  DejaGnu already
  128.   runs under BSD, and Cygnus is porting it to Linux.
  129.  
  130.   Our goal is to test as many parts of the system as possible,
  131.   including system calls (particularly for POSIX 1003.1 compliance),
  132.   libraries in the official distribution, networking protocols,
  133.   and utilities.  We need help with
  134.  
  135.     1) integrating good tests donated by the community (and probably
  136.        written in a variety of programming languages and command
  137.        shells) into the DejaGnu framework, and
  138.  
  139.     2) writing new tests for major functional areas for which no
  140.        adequate tests exist.
  141.  
  142.   The tests we use will be placed under the GPL and distributed by
  143.   Cygnus Support along with DejaGnu.  H. K. Lu, who maintains the C
  144.   library for Linux, has offered to run the POSIX 1003.1 tests and as
  145.   many others as he can.
  146.  
  147. Process
  148.  
  149.   First let me summarize the advantages of using DejaGnu, a free
  150.   software product that will be the umbrella for all the tests, and
  151.   then explain how we plan to conduct this project.
  152.  
  153.   Cygnus Support released DejaGnu to the public on January 3, along
  154.   with several test suites for GNU language tools.  The product is
  155.   designed for portability and easy cross-platform development and
  156.   execution.  It works more uniformly than typical tests using the
  157.   UNIX shell, and also supports interactive testing better than most
  158.   test platforms -- for instance, Cygnus has written over 1300 unit
  159.   tests for the gdb debugger using it.
  160.  
  161.   The implementation of DejaGnu is based on tcl and expect, two simple
  162.   existing languages for writing commands.  You can develop new tests
  163.   in two major ways: by placing keyword-based comments in C source
  164.   code, or by writing tests in tcl.
  165.  
  166.   While Cygnus is still increasing their body of tests for language
  167.   tools, they are also turning their resources toward the libraries
  168.   and GNU utilities.  While most of the tests are written at Cygnus,
  169.   they have reached out to communities of testers and are now porting
  170.   substantial sets of donated tests.
  171.  
  172.   We are hoping to broaden this successful use of collaboration across
  173.   user communities.  We hope that suites of useful tests are sitting
  174.   in desk drawers out there.  We also hope to gather and mobilize
  175.   people who appreciate the value of formal tests in legitimizing free
  176.   software, and would like to help write them.
  177.  
  178.   I am not an employee of Cygnus, but have volunteered to talk to
  179.   interested people and do an initial classification of tests, just to
  180.   offload some of this routine work from them.  I will discuss all
  181.   offers with Cygnus staff to find out what is most needed and decide
  182.   which tests to incorporate into DejaGnu.  There are several criteria
  183.   for choosing tests, including the degree to which an area is
  184.   covered, and its importance in the overall stability of the
  185.   operating system.  Some tests may have to be rejected just because
  186.   they are hard to fit into the DejaGnu model.
  187.  
  188. People
  189.  
  190.   Now you can find out why each of us got involved with this project.
  191.  
  192.   Cygnus writes and distributes free software, selling support as a
  193.   means to make money.  The company is not directly in the business of
  194.   supporting operating systems or common UNIX utilities, so this kind
  195.   of testing is tangential to their main goals.  But they may want to
  196.   support those things in the future.  In any case, they would like to
  197.   see Linux do well, and this big test project will be a good
  198.   promotion for DejaGnu.
  199.   H. K. Lu, as a volunteer for Linux, has been using his own system to
  200.   implement, port, maintain, and ensure ANSI and POSIX compliance for
  201.   the C library (mostly the GNU C library along with the iostream
  202.   class from the g++ library).  He is looking for ways to validate the
  203.   work that he and many other contributors have put in.
  204.  
  205.   As an editor at a publisher of computer books, my relationship to
  206.   Linux and BSD is even more distant than that of Cygnus.  But we are
  207.   thinking about putting out books about Linux, from either the Linux
  208.   Documentation Project or independent authors, and would like to make
  209.   sure Linux is stable enough to be documented.  The testing of
  210.   utilities is particularly important to me, because it can provide
  211.   quality assurance for our books, including the BSD version of UNIX
  212.   in a Nutshell.
  213.  
  214. What you can do
  215.  
  216.   We ask people who have written tests in the areas I have described
  217.   to donate them to this project and see them benefit the public.
  218.   Don't just send me stuff -- write or call to discuss what you've got
  219.   in general.  You also have to assign the tests to the Free Software
  220.   Foundation (a simple matter, so long as you are the owner of the
  221.   tests) so that they can be distributed under the GPL.
  222.  
  223.   Also, please don't starting flaming about the GPL.  Either join our
  224.   project and donate your tests, or don't.  Personally, I do not take
  225.   a side in this war.
  226.  
  227.   People who are interested in testing as a discipline, and have some
  228.   time to donate, are invited to contact me to help write tests.  Tell
  229.   me:
  230.  
  231.         Your knowledge of computer languages and tools
  232.  
  233.         Previous software test efforts you have engaged in, if any
  234.  
  235.         How much time you can devote
  236.  
  237.         What functional areas you think are important and have a
  238.         particular interest in
  239.  
  240.   Cygnus staff will tell volunteers which areas need testing, and
  241.   offer guidance while you learn and apply DejaGnu.  The most
  242.   important trait for the project is rigorous thinking along the lines
  243.   of software quality (so the best preparation is to have done some
  244.   formal testing before).  You do not need to know any particular
  245.   language or tool; you can learn tcl or other aspects of DejaGnu
  246.   fairly quickly.
  247.  
  248.   Contact information for me is in my signature.  I am at the phone
  249.   number during traditional U.S. business hours.  So send mail any
  250.   time, or try calling from Monday through Friday, 9:00 AM to 5:00 PM,
  251.   Eastern Daylight Saving Time (four hours later than Greenwich Mean
  252.   Time).
  253.  
  254.   Feel free to distribute and repost this message elsewhere, in its
  255.   entirety.
  256.  
  257. ----------------------------------------------------------------------
  258. Andy Oram    O'Reilly & Associates, Inc.                 andyo@ora.com
  259.              90 Sherman Street, Cambridge, MA 02140     (617) 354-5800
  260.                                                     fax (617) 661-1116
  261. ----------------------------------------------------------------------
  262.